#include <wx/string.h>

namespace llm
{
const std::string PROMPT_DOCSTRING_GEN =
    R"#(You are an expert software developer. Write a complete, idiomatic documentation comment for the function whose source code is provided below.

The comment must be suitable for being placed **directly above** the function definition and should follow the most common documentation style for the language in which the function is written (e.g., Javadoc for Java, docstring for Python, Doxygen for C/C++, JSDoc for JavaScript/TypeScript, Rustdoc for Rust, etc.).

The documentation comment must contain **all** of the following sections (in this order, if the language supports them):

1. **Brief summary** – one‑sentence description of what the function does.
2. **Detailed description** – one or two sentences (optional) expanding on the summary, clarifying side‑effects, algorithmic notes, or important constraints.
3. **Parameters** – a list of each parameter, its type (if not already obvious from the signature), and a concise description of its purpose.
4. **Return value** – the type (if applicable) and description of what is returned. If the function returns nothing, explicitly state that.
5. **Raises / Throws / Errors** – any exceptions, error codes, or error‑handling behavior the function may produce. If none, you may omit this section.
6. **See also** – (optional) references to related functions, classes, or external documentation.

Follow the exact syntax for the target language’s doc‑comment style (e.g., `/** … */` for Java, `""" … """` for Python, `/// …` for Rust, `/** … */` for TypeScript/JSDoc, `/*** … */` for Doxygen, etc.).

Do **not** include any extra explanatory text outside the comment block.
If the function is a method belonging to a class, also include a brief note about the class/context if it helps the reader.

---

**Function source:**

```{{lang}}
{{function}}
```

---

Generate only the documentation comment (no surrounding code).
)#";

const std::string PROMPT_GIT_COMMIT_MSG =
    R"#(You are an expert software‑engineer who writes clear, conventional GitHub commit messages.

## Requirements
* The first line (the **title**) must be ≤ 80 characters.
* The title must be written in **title case**, start with a **imperative verb** (e.g. “Fix”, “Add”, “Refactor”, “Update”), and must not end with a period.
* After the title leave a **blank line**.
* The body may contain one or more paragraphs that:
  * Summarize **what** was changed (high‑level overview, not a line‑by‑line description).
* If the change touches multiple logical areas, add a short **“* <area>”** bullet list at the end of the body.
* Do **not** repeat the diff verbatim in the commit message; use it only as source material for understanding the change.
* Append a footer with the following text at the end of the generated commit message: "** Generated by CodeLite. **"

## Input
Below is the `git diff` of the change you need to describe. Use it to infer the intent of the change, the files involved, and any important code‑level details (e.g. added/removed public APIs, refactorings, bug‑fixes, test additions, etc.).


```diff
{{context}}
```

## Output
Produce **only** the commit message, in the exact format described above (title, blank line, body). Do not add any extra explanations, code blocks, or markdown.
)#";

const std::string PROMPT_GIT_RELEASE_NOTES =
    R"(You are an expert technical writer who creates concise, well‑structured release notes for public websites.

Your job:
1. Read the raw commit list below (one commit per line).
2. Group the changes into the following sections **only if there is at least one item**:
   - **✨ New Features** – new public‑facing functionality.
   - **🐛 Bug Fixes** – corrections of defects.
   - **🔧 Improvements / Refactorings** – internal enhancements, performance, code cleanup, etc.
   - **📝 Documentation** – docs, READMEs, comments, examples, API docs.
   - **⚠️ Breaking Changes** – anything that might require users to change their code or configuration.
   - **🚀 Other** – anything that doesn’t fit above (e.g., CI/CD updates, test additions, build scripts).

3. For each commit, keep only the essential part of its subject line (ignore the hash, date, author).
   - If the commit message already contains a conventional prefix (e.g., `feat:`, `fix:`, `docs:`), **use that to decide the section**.
   - If no conventional prefix exists, infer the section from the wording, falling back to **Other**.

4. Write the release notes in **GitHub‑flavored Markdown** suitable for direct copy‑paste onto a web page.
   - Use level‑2 headings (`##`) for each section.
   - Use bullet points (`-`) for individual items.
   - Append a short link to the commit hash that points to GitHub (or your Git remote) using the format `[hash](https://github.com/ORG/REPO/commit/hash)`.
   - If a commit references a PR number (e.g., `#123`), turn it into a link `[#123](https://github.com/ORG/REPO/pull/123)`.

5. At the top of the document, add a title line with the release version and date, formatted exactly as:

   ```markdown
   # Release {{VERSION}} – {{RELEASE_DATE}}
   ```

6. End the notes with a short “_Thank you for using our software!_” line.

---

### Input (replace this block with your real data)

```
{{context}}
```
)";

const std::string PROMPT_GIT_RELEASE_NOTES_MERGE =
    R"(Rephrase the following release notes text. Remove duplicate entries and merge the sections.

Add a summary section that contains list of contributors and the number of commit they did.

Here are the release notes:

```markdown
{{context}}
```
)";

const std::string PROMPT_GIT_CODE_REVIEW =
    R"(You are an expert developer performing a code review. Your task is to analyze the provided git diff and offer constructive feedback.

Your review should cover the following points:
1.  **Code quality and best practices:** Are standard patterns followed? Is the code readable? Is it adhering to the DRY (Don't Repeat Yourself) principle?
2.  **Potential bugs and logical errors:** Identify any obvious issues or edge cases that might cause problems.
3.  **Performance implications:** Flag any changes that might negatively impact performance.
4.  **Security vulnerabilities:** Point out any security risks introduced by the changes.
5.  **Maintainability:** Are the changes easy to understand and maintain over time?

Provide a concise summary at the beginning of your review. For each suggestion, use a GCC style format.
If you provide a code example for an improvement, include the filename where the change should be applied.

Here is the git diff to review:

```diff
{{context}}
```

Here are some examples:

## Example:

Example input git diff:

```diff
diff --git a/Plugin/CustomControls/TextGenerationPreviewFrame.cpp b/Plugin/CustomControls/TextGenerationPreviewFrame.cpp
index fa39e40fd..12e491747 100644
--- a/Plugin/CustomControls/TextGenerationPreviewFrame.cpp
+++ b/Plugin/CustomControls/TextGenerationPreviewFrame.cpp
@@ -84,7 +84,9 @@ void TextGenerationPreviewFrame::OnCopy(wxCommandEvent& event)
     wxString text = m_editor->GetText().Trim().Trim(false);

     auto stripped_text = StripMarkdownCodeBlocks(text.ToStdString(wxConvUTF8));
+    char *a = new char[120];
+    strcpy(a, stripped_text.c_str());
+    return a;

```

Example output:

```
Plugin/CustomControls/TextGenerationPreviewFrame.cpp:87: warning: potential memory leak?
Plugin/CustomControls/TextGenerationPreviewFrame.cpp:88: warning: make sure no buffer overflow.
```)";
} // namespace llm
